ReduxってEffect Systemっぽいね的な話、BLoCについての考察

Effect System is 何

副作用を値として表現したEffectを処理することで、柔軟な副作用の処理をしようとするシステム/アプローチ(?)

筆者の理解です

大体、抽象的なEffectをハンドラでより具体的なEffectの列に変換するみたいなスタイルな気がする

そして末端のハンドラが具体的なEffectを実行して副作用を処理する

抽象的なEffectを処理するハンドラがDIとかにおける実装の役割をする

ReduxってEffect Systemじゃね

Redux Architecture https://gyazo.com/d51de61a1f6836cc21e1232dc56179d2

最初Reduxのチュートリアル的なものを見たとき、「ActionとReducer分ける必要なくない？Reducerの関数をStoreに直接適用すればいいでしょ」って思った人もいるかもしれない

tosuke.iconもそう思っていました

実際そういう思想の状態管理ライブラリも存在する jaystack/repatch: Dispatch reducers

実はそれではだめで、MiddlewareのためにActionをオブジェクトとして扱う必要性(必然性かも)がある

MiddlewareはActionを受け取り、(副作用を含む)なんやかんやをして任意のタイミングでActionを発行する

実例として、APIへのfetchを処理するMiddlewareを考える

Storeは{ fetching: boolean, data: Data | null, error: unknown } という型を持ち、 Requested, Fetched, Failed という3つのActionが定義されている

Requestedはfetchingをtrueに、Fetchedはdataに値を、Failedはerrorに値を入れ、FetchedとFailedはfetchingをfalseにもする

MiddlewareはRequestedが来たらAPIリクエストを発行し、成功したらFetchedを、失敗したらFailedを発行する

これは(時間差を無視すれば)Requestedを[ Requested, Fetched ]とか[ Requested, Failed ]に変換したことになる

これってEffect Systemっぽくないですか？？？？

ところで、「時系列のある列」ってStreamっぽい

まんまredux-observableとかあるし

Model-View-Intentアーキテクチャもこれに近い(というかほとんど同じ)ことを考えているように見える

こっちはもう少し責務の分割を積極的にやっているイメージ、個人的には最初からそこまでやっていく必要があるのか？という気持ちになるが、大きいアプリケーションを考えていく上では割と必然性があるのかもしれない

これはこぼれ話なんですが、Reduxの元ネタになった(あえてパクリ元とは言わない)The Elm ArchitectureにはMiddlewareはなくて、代わりにCommandという仕組みがある

Reducerで更新後の状態と一緒にCommandを返すと、ランタイムが副作用を実行してその結果をActionとしてDispatchしてくれる

Commandはmapしたり組合せたりできるので、ここがMiddlewareと同じことをやってる気がする

完全に同じだったらパクリだけど、Middlewareという独自の概念を発明してるからリスペクトみたいなとこある

最後にActionを受け取るReducerはミーリマシンっていうオートマトンの一種らしい

それはね，そう

ところでBLoCというものがありまして

なんで公式資料が動画だけなんだ…

入出力がStreamとか、限られた情報しかない

結果として、設計が自由すぎる

適当に書くと各BLoCがBehaviourSubjectで状態を持ちはじめて治安が悪くなる

状態管理を上位のBLoCに丸投げしたい

Redux的なやつで状態管理して、末端のBLoCはMiddleware的に働く

そうすれば治安の良い(Testableな)BLoCを書くことができそう

やりたい

BLoCは難しい

まとめ

まとまらない